The present invention relates to the interface between middleware and the underlying transport services (e.g. network stack) that allow separate processes and computers to communicate with each other.
In the context of this invention, middleware is a layer of software that lies between a lower layer or software (typically the operating system) and higher layers of software which include the end-user application. Middleware can implement one or more communication models and offer those as a service to the higher layers. For instance middleware can implement a real-time publish-subscribe communications model to allow distributed processes to share data without concern for the actual physical location or architecture of their peers. The middleware may include support for best-effort and reliable communications. For example, the Object Management Group's (OMG) Data Distribution Service for Real-Time Systems (DDS) is a standard specification for middleware that implements and offers a publish-subscribe data-distribution system model to the software layers above. The purpose of the specification is to provide a common application-level interface that clearly defines the capabilities and behavior of the data-distribution service.
DDS uses a publish-subscribe (P-S) communication model. The P-S communication model employs asynchronous message passing between concurrently operating subsystems. The publish-subscribe model connects anonymous information producers with information consumers. The overall distributed system is composed of processes, each running in a separate address space possibly on different computers. In this patent application, each of these processes of the distributed system is referred to as a “participant application”. A participant application may be a producer or consumer of data, or both.
Using the middleware, data producers declare the topics on which they intend to publish data; data consumers subscribe to the topics of interest. When a data producer publishes some data on a topic, the middleware operates such that all the consumers subscribing to that topic receive it. The data producers and consumers remain anonymous, resulting in a loose coupling of sub-systems, which is well suited for data-centric distributed applications. This is referred to as a DCPS (data-centric publish subscribe) architecture.
The DCPS model employs the concept of a “global data space” of data-objects that any entity can access. Applications that need data from this space declare that they want to subscribe to the data, and applications that want to modify data in the space declare that they want to publish the data. A data-object in the space is uniquely identified by its keys and topic, and each topic has a specific type. There may be several topics of a given type. A multiplicity of independent Global Data Spaces may be created. Each global data space is identified by its domain id. Each subscription/publication must belong to the same domain in order to communicate.
For example, the reader is referred to the Object Management Group's Specification entitled “Data Distribution Service for Real-Time Systems Specification,” Version 1.1, dated December 2005. See http://www.omg.org/docs/formal/05-12-04.pdf (referred to herein as “DDS Specification”). In the DDS Specification, a DCPS architecture is specified that includes the following entities: DomainParticipant, DataWriter, DataReader, Publisher, Subscriber, and Topic. All these classes extend Entity, which is an abstract base class for all the DCPS objects that support QoS policies, a listener, and a status condition. The particular extension of Entity represents the ability to be configured through QoS policies, be enabled, be notified of events via listener objects, and support conditions that can be waited upon by the application. Each specialization of the Entity base class has a corresponding specialized listener and a set of QoSPolicy values that are suitable to it.
A Publisher represents the object responsible for data issuance. A Publisher may publish data of different data types. A DataWriter is a typed facade to a publisher; participants use DataWriter(s) to communicate the value of and changes to data of a given type. Once new data values have been communicated to the publisher, it is the Publisher's responsibility to determine when it is appropriate to issue the corresponding message and to actually perform the issuance (the Publisher will do this according to its QoS, or the QoS attached to the corresponding DataWriter, and/or its internal state).
A Subscriber receives published data and makes it available to the participant. A Subscriber may receive and dispatch data of different specified types. To access the received data, the participant must use a typed DataReader attached to the subscriber.
The association of a DataWriter object (representing a publication) with DataReader objects (representing the subscriptions) is done by means of the Topic. A Topic associates a name (unique in the system), a data type, and QoS related to the data itself. The type definition provides enough information for the service to manipulate the data (for example serialize it into a network-format for transmission).
The DDS middleware handles the actual distribution of data on behalf of a user application. The distribution of the data is controlled by user settable Quality of Service (QoS).
Data distribution middleware is characterized by delivery of data over a variety of physical and logical communication media such as Ethernet-based networks, other LAN, Wireless, or WAN technologies, shared-memory, local busses (PCI, VME), high-speed serial interconnects, etc. A flexible approach is needed to enable the specification, configuration, and seamless usage of multiple transport networks in a data distribution system.